[Previous] [Next] [Index] [Thread]

Re: New York Times article

chris garrigues wrote:
> I really don't see what NFS has to do with netscape security.

the point is that many sites make security-capable clients
available with nfs and other protocols that don't do
integrity-checking. gauthier et al can modify those clients
while they're in transit, without fear of detection. for
eaxample, they could patch the executables you receive, so that
the modified client code mails your password or your credit-card
number to berkeley. in netscape's case, an even easier patch would
just change the browser's copy of the verisign certification-
authority public key. this change makes your browser vulnerable
to a man-in-the-middle attack, which is very hard to detect,
and is also very hard to prevent. i've appended a description of
this attack, below. my description doesn't mention gauthier's
attack, because gauthier hadn't announced it at that time.

while it's not news that nfs is insecure, the insecurity that
people commonly knew about was a different one, concerning
privacy and access-control. on-the-fly message-integrity attacks
have commonly been thought to be impractically difficult. thus,
the nyt article was far from content-free; it's a wake-up call
for the networking industry.

					-don davis, boston

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
From: don@cam.ov.com (Donald T. Davis)
Newsgroups: alt.security,sci.crypt,alt.security.pgp,talk.politics.crypto
Subject: netscape's ssl flaws
Date: 6 Oct 1995 12:26:47 -0400
Organization: OpenVision Technologies, Inc.

david sternlight wrote:
>> Netscape had not used a fully random bit string to generate session keys,
>> but rather some of the bits were easily determined by a hacker.

jim gillogly responded:
> There were three recent Netscape cracks:
> The first one was a challenge prepared by Hal Finney for a 40 bit Netscape
> session, and Damien Doligez of INRIA (France) cracked it...
> The second challenge, also prepared by Hal Finney, was again for a 40 bit
> Netscape session, and it was cracked by a large team of Cypherpunks...
> The third crack was the one you refer to, which, in the most favorable
> conditions, resulted in finding the correct key in under a minute. 

here are some other weaknesses in netscape's ssl:

an early version of netscape's software used a weak prng to generate keys.

an early version of the ssl spec made no provision for message-integrity
checking, which is very necessary with a vernam cipher like rc4.

in 7/95, i presented a man-in-the-middle attack on netscape's ssl,
at the 1st usenix workshop on electronic commerce in manhattan. my
attacker would distribute altered netscape browsers, containing
spurious certification-authority keys. users of these browsers will
then accept forged merchant certificates from the attacker. the
attacker sets up a simultaneous session with the merchant, translating
the encryption of the key-sharing messages. once the session-key is
established, the attacker's active role ends; with the session-key
in hand, he eavesdrops on the rest of the session. note that this is
not the m-i-t-m attack addressed in the ssl specification by el gamal.

my attack exploits three flaws in netscape:
  * no secure channel for the verisign CA key: the netscape browser
    executables are easy to modify in this way, but are hard for a
    naive user to integrity-check.
  * freeware distribution of executables: netscsape's browser is
    commonly redistributed by other sites, including insecure
    academic sites.
  * without client-side authentication, the merchant's server can't
    detect the man-in-the-middle.

of these flaws, client-side authentication would seem to be the
easiest to fix: the client uses the merchant's public-key first,
then signs the resulting ciphertext with his own private key.
however, signing ciphertext is vulnerable to another attack,
as was pointed out by burrows, abadi, & needham in '89, and by
i'anson & mitchell in '90. so, it's necessary to sign some of
the plaintext, encrypt the signature, and sign the ciphertext,
too. this solution is pretty cumbersome.

i might also remark that their recent random-seed generation problem
is not merely a "bug." it is very hard to fix, and netscape's track
record shows that they're unlikely to get it right.

					-don davis, boston
References: